-
Notifications
You must be signed in to change notification settings - Fork 652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor http response status equatable #335
Refactor http response status equatable #335
Conversation
Can one of the admins verify this patch? |
1 similar comment
Can one of the admins verify this patch? |
@helje5 pulling this convo in from #327.
are you stating that custom anything lhs/rhs should be cased out, I can see the motivation for that. It is still much shorter then long case statement. I will make change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would intuit that:
"404 Not Found" == "404 not found" // true
Why not just compare the code?
@tanner0101 I completely agree from a web perspective the HTTP code is all that matters not the text description as localization could very well cause problems there. I think this would alter the enum's current behavior though. Further, the refactor could probably be reduced to just the enum conforming to the interface. |
I think what we have here is mimic the same as we had before. If we want to change this another PR should be done IMHO. |
@swift-nio-bot test this please |
@pedantix IMO using a closed enum in a open API is deeply flawed in the first place, as demonstrated by the teapot (apart from the SemVer major source incompatibility you introduce by adding a case, the ugliness of custom, and all the bugs revolving around the .custom pattern). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I think we should keep the current behaviour of the equatable enum on custom codes.
What could be done is to group all the |
@Lukasa does the code in my PR not keep the current behavior? As I read it, there is an ever-growing number of cases that pattern matches on if custom compares stored values, if not compare match on equal symbols(which is the source of the growth) if not default to false. I may be missing a swift subtlety but my PR is not aimed at changing functionality just reducing growth. There is definitely a weakness with using a default case. As @BasThomas says all the true pairs could be reduced to a single case, I am not sure if this is any better in terms of readability. |
Sorry, you're right. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weissi Mind taking a look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry for the massive delay! thanks very much for the patch, lgtm!
@swift-nio-bot test this please |
@pedantix thanks! |
@normanmaurer @weissi @Lukasa thank you! -119 lines of code as a net gain I think is just cool. This project is so great to make use of thanks!!! |
Refactored
extension HTTPResponseStatus: Equatable
, no change to the efficacy of the code.Motivation:
Code readability is essential to a long-lasting maintainable project, the code this PR changes was "readable" however this PR will enhance the readability by removing excess lines of code.
Modifications:
Changed a long case statement, to a much shorter one.
Result:
There will be fewer lines of code, no change to the efficacy of product should occur. I am not familiar enough with the compiler to know if this will have a deleterious effect on performance I don't think it should be based on the way
public var code: UInt { get }
is implemented.